Kicksecure Security Roadmap
Donate
Future Kicksecure Security Enhancements
Introduction[edit]
Kicksecure aims to incorporate an advanced security model designed to defend against evolving threats. Most if not all desktop Linux distributions in their current state provide insufficient protection. [1] [2] These issues are unspecific to Kicksecure. As such, Kicksecure developers have a lot of work to do. This page describes the goals, current status and limitations of our work. Dedicated wiki pages outline each sub-project in further detail.
Readers should note that most of the topics discussed here are still in development and are not yet used by default. Contributions and testers are most welcome.
Future Enhancements[edit]
Principle of Least Privilege[edit]
Vulnerabilities in software are inevitable, therefore their impact must be contained by isolating processes. The Kicksecure design has adopted the principle of least privilege
and security by isolation concept in order to mitigate security threats.
Firstly, a full system AppArmor policy is in development to confine all user space processes on the system. This will be foundational to the security model and allow the implementation of strict mandatory access control restrictions on all processes, as well as finer-grain control over what they can access. Essentially desktop Linux can imitate design ideas already present in other more robust operating systems like Android (issues with Android). In addition to locking down user space, this also protects the kernel because it restricts access to kernel interfaces like /proc or /sys, reducing the likelihood of kernel pointer and other leaks.
Furthermore, applications in the future will be executed inside sandbox-app-launcher. This runs each application as its own user, inside a bubblewrap sandbox and confined by AppArmor with a robust permission model. The end goal is most user-installed applications will be automatically configured to utilize sandbox-app-launcher, including common applications like web browsers and messengers (but not lower-level system utilities).
The main drawback of this approach is the desktop Linux software stack was not written with isolation in mind. A delicate balance is necessary when restricting processes so user applications and the desktop OS remain fully functional. This stands in stark contrast to operating systems like Android which were designed to contain the entire operating system and application ecosystem with SELinux and the application sandbox. [3] [4] [5]
Further reading:
User Space Exploit Mitigations[edit]
Mitigating common classes of vulnerabilities and exploit techniques is also on the Kicksecure security roadmap, but the possible mitigations are limited at present.
sandbox-app-launcher enforces a strict W^X ("write xor execute") policy [6] to prevent attackers from executing new arbitrary/malicious code. This will force attackers to utilize the already existing code -- for example Return-oriented programming (ROP) / Jump-Oriented-Programming (JOP) -- which is far more limiting and difficult to achieve. Unfortunately, some applications (mainly web browsers due to just-in-time compilation (JIT)) [7] [8] [9] must be whitelisted. Currently, there is no protection for system services that run outside of sandbox-app-launcher — it is unclear how this could be implemented. Kicksecure could possibly add its own seccomp wrapper, wait for S.A.R.A., use systemd's MemoryDenyWriteExecute, or other measures.
Additional mitigations like CFI, SafeStack, automatic stack variable initialization and others are highly desirable but are unlikely to be utilized due to current project resourcing.
Further reading:
Kernel Hardening[edit]
Securing user space is a worthy security goal, but it is insufficient in isolation because it leaves the kernel as a soft target. In response Kicksecure is developing hardened-kernel and security-misc in an attempt to improve the state of kernel security. Linux Kernel Runtime Guard is also used to help defend against off-the-shelf malware, but it will not help against dedicated or advanced adversaries because it is not difficult to bypass.
Kicksecure is unable to completely address kernel security issues because they are rooted deep within its design and upstream developers are not very focused on serious security enhancements; see footnotes. [10] [11] [12] [13]
Further reading:
Malware Persistence[edit]
If malware is capable of bypassing other protections, Kicksecure aims to prevent it from persisting. In future, verified boot will be used to verify the boot chain and base system, likely by chaining UEFI Secure Boot with dm-verity. [14] This will be a difficult endeavor due to the layout of traditional desktop Linux distributions. Once this is implemented, there will be two main remaining vectors for malware persistence:
- Malware residing in a persistent state.
- Malware residing in the device firmware.
The first problem can be largely solved with apparmor.d and sandbox-app-launcher. By severely reducing the level of trust granted to the persistent state, the threat of serious harm from any resident malware is reduced and it is contained within its own sandbox.
The second problem cannot be solved by the Kicksecure project. Instead, users need to rely on solutions like Intel Boot Guard or AMD Secure Boot (different from UEFI Secure Boot) to verify the integrity of the firmware. Unfortunately these options are not very common.
Kicksecure has adopted a best-effort, but admittedly quite weak approach. VirusForget attempts to deactivate malware after a reboot from a non-root compromise, by restoring sensitive files. This prevents malware from persisting through files such as ~/.bashrc. However, this is not a strong defense and it will not defeat the efforts of an active adversary.
Further reading:
Additional Security Measures[edit]
- Remount Secure
- SUID Disabler and Permission Hardener
- Reduce Kernel Information Leaks
- Multiple Boot Modes for Better Security (user, live, secureadmin, superadmin)
Forum Discussion[edit]
See Also[edit]
- Fixing the Desktop Linux Security Model
- About Computer (In)Security
- Testers for New Security Features Wanted!
Footnotes[edit]
- ↑
Fixing the Desktop Linux Security Model
- ↑
Linux (In)security
- ↑
Security-Enhanced Linux in Android
- ↑
Android: Application Sandbox
- ↑
- ↑
W^X... is a security feature in operating systems and virtual machines. It is a memory protection policy whereby every page in a process's or kernel's address space may be either writable or executable, but not both. Without such protection, a program can write (as data "W") CPU instructions in an area of memory intended for data and then run (as executable "X"; or read-execute "RX") those instructions. This can be dangerous if the writer of the memory is malicious.
- ↑
...(JIT) compilation (also dynamic translation or run-time compilations) is a way of executing computer code that involves compilation during execution of a program (at run time) rather than before execution. Most often, this consists of source code or more commonly bytecode translation to machine code, which is then executed directly. A system implementing a JIT compiler typically continuously analyses the code being executed and identifies parts of the code where the speedup gained from compilation or recompilation would outweigh the overhead of compiling that code.
- ↑ As JIT compilation uses executable data directly in memory, this can lead to exploits if execution is moved into the heap; writable/executable memory is a security hole since code is normally written to memory and marked read-only.
- ↑ JIT leads to a faster browsing experience but opens up a large number of potential exploits, see: Microsoft Launches JIT-Free 'Super Duper Secure Mode' Edge Browser Experiment.
- ↑ Net of insecurity: The kernel of the argument
- ↑ https://grsecurity.net/~spender/interview_notes.txt
- ↑ More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method
- ↑ 10 Years of Linux Security: A Report Card
- ↑
Device-Mapper’s “verity” target provides transparent integrity checking of block devices using a cryptographic digest provided by the kernel crypto API. This target is read-only.
A secure by default operating system with the latest security research in place.
At
Kicksecure we value freedom and trust, supporting Open Source and Freedom Software
2012-
2024 ENCRYPTED SUPPORT LP
We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!